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TANA Rules for MIKEY (Multimedia Internet KEYing) 


Abstract 
This document clarifies and relaxes the IANA rules for Multimedia 
Internet KEYing (MIKEY). This document updates RFCs 3830, 4563, 
5410, and 6043; it obsoletes RFC 4909. 

Status of This Memo 


This is an Internet Standards Track document. 
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Internet Standards is available in Section 2 of RFC 5741. 
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Les 


Introduction 


This document relaxes the IANA rules for Multimedia Internet KEYing 
(MIKEY) [RFC3830]. The IANA rules defined in [RFC3830], [RFC4563], 
[RFC4909], and [RFC5410] are affected. In addition, the rules 
specified in [RFC6043] are re-specified here. 


Most of the values in MIKEY namespaces are divided into two ranges: 
"TETF Review" (or "IETF Consensus" as it was previously called) and 


"Reserved for Private Use" [RFC5226]. This document changes, for 
majority of the namespaces, the requirement of "IETF Review" to "IETF 
Review or IESG Approval" [RFC5226]. For some namespaces, the 


requirement is changed to "Specification Required" [RFC5226]. 


The rationale for this update is that there can be situations where 
it makes sense to grant an allocation under special circumstances or 
that time has shown that the current requirement is unnecessarily 
strict for some of the namespaces. By changing the current IANA 
rules to also allow for "IESG Approval" [RFC5226], it becomes 
possible for the Internet Engineering Steering Group (IESG) to 
consider an allocation request, even if it does not fulfill the 
default rule. For instance, an experimental protocol extension could 
perhaps deserve a new payload type as long as a sufficient number of 
types still remains, and the MIKEY community is happy with such an 
allocation. Moreover, for some registries, a stable specification 
would be a sufficient requirement, and this is thus reflected in the 
updated IANA rules. For instance, an RFC via the Independent Stream 
at the RFC Editor is sufficient for some registries and does not 
force an IETF evaluation of a particular new extension for which 
there is no general demand. Nevertheless, "IETF Review" is still 
encouraged (instead of using the "IESG Approval" path) if there is 
doubt about whether or not it is needed for a new allocation. 


The rest of this document is structured as follows. Section 2 
defines the new IANA rules. Section 3 discusses the security 
implications of this document. Sections 4, 5, 6, and 7 explain the 
changes to [RFC3830], [RFC4563], [RFC4909], [RFC5410], and [RFC6043]. 


IANA Considerations 


IANA updated the registries related to MIKEY as specified below. All 
other MIKEY IANA registries remain unchanged. 


New values for the version field ([RFC3830], Section 6.1) and the C 
envelope key cache indicator ([RFC3830], Section 6.3) field can be 
allocated via "IETF Review". 
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The "IETF Review" requirement for adding new values into namespaces, 
originally defined in [RFC3830], is to be changed to "IETF Review or 
IESG Approval". This change affects the following namespaces: 

o data type ([RFC3830], Section 6.1) 

o Next payload ([RFC3830], Section 6.1) 

o PRF func ([RFC3830], Section 6.1) 

o CS ID map type ([RFC3830], Section 6.1) 


o Encr alg ([RFC3830], Section 6.2) 


o MAC alg ([RFC3830], Section 6.2) 


o DH-Group ([RFC3830], Section 6.4) 

o S type ([RFC3830], Section 6.5) 

o TS type ([RFC3830], Section 6.6) 

o ID Type ([RFC3830], Section 6.7) 

o Cert Type ([RFC3830], Section 6.7) 

o Hash func ([RFC3830], Section 6.8) 

Oo SRTP Type ([RFC3830], Section 6.10) 

Oo SRTP encr alg ([RFC3830], Section 6.10) 
Oo SRTP auth alg ([RFC3830], Section 6.10) 
o SRTP PRF ([RFC3830], Section 6.10) 

o FEC order ([RFC3830], Section 6.10) 

o Key Data Type ([RFC3830], Section 6.13) 


o KV Type ([RFC3830], Section 6.13) 
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The "IETF Review" requirement for the following registries, 
originally defined in [RFC3830], [RFC4563], [RFC4909], and [RFC5410], 
is to be changed to "Specification Required". 

o Prot type ([RFC3830], Section 6.10) 

o Error no ([RFC3830], Section 6.12) 

o General Extension Type ([RFC3830], Section 6.15) 

o KEY ID Type ([RFC4563], Section 4) 


o OMA BCAST Data Subtype ([RFC5410], Section 3) 


The "Specification Required" requirement remains for the following 
namespaces: 


o TS Role ([RFC6043], Section 6.4) 

o ID Role ([RFC6043], Section 6.6) 

o RAND Role ([RFC6043], Section 6.8) 

o Ticket Type ([RFC6043], Section 6.10) 

The range of valid values for certain namespaces defined in the IANA 


considerations of [RFC3830] was not explicitly defined and is 
clarified here as follows: 


t---- 5-5 E E E +-------------- + 
| Namespace | Valid values | 
t----- 7-5-5 T E E EA +-------------- + 
| C Envelope Key Cache Indicator | 0 - 3 | 
S type 0 - 15 
Key Data Type Q = 15 
| KV Type 0i | 
A E a +-------------- + 
3. Security Considerations 


This specification does not change the security properties of MIKEY. 
However, when new values are introduced without IETF consensus, care 
needs to be taken to assure that possible security concerns regarding 
the new values are still addressed. 
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4. 


8. 


8. 


Changes from RFC 3830 


Section 2 relaxes the requirements from those defined in [RFC3830]. 
A number of namespaces now have the "IETF Review or IESG Approval" 
requirement, when they previously had the "IETF Review" requirement. 
In addition, some namespaces now have the "Specification Required" 
requirement. 


Changes from RFC 4563 


Section 2 relaxes the requirements from those defined in [RFC4563]. 
The KEY ID Type namespace now has the "Specification Required" 
requirement. 


Changes from RFC 4909 and RFC 5410 


Section 2 relaxes the requirements from those defined in [RFC4909]. 
The OMA BCAST Data Subtype namespace now has the "Specification 
Required" requirement. Note that [RFC5410] obsoleted [RFC4909] but 
does not actually define the IANA rules itself. As a result, from 
now on, this RFC defines the IANA requirements for the OMA BCAST Data 
Subtype namespace. 


Changes from RFC 6043 


There are no changes to the rules specified in [RFC6043]. However, 
for sake of completeness, Section 2 re-specifies these rules in this 
document, and from now on, this RFC defines the IANA requirements for 
those namespaces. 
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